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2 he boot sequence for a machine typically starts — 

— — reg management controller] 

(platform controller hub). In the case of an 

: =| Intel CPU, the Intel Management Engine runs in the 

PCH and starts before the CPU. After configuring 

_ the machine's hardware, the BMC [or PCH, depending 

_ onthe system] allows the CPU to come out of reset. 

_ The CPU then loads the boot firmware (or UEFI, unified 

extensible firmware interface] from the boot firmware 

_ SPI (Serial Peripheral Interface] flash. The boot firmware 

_ then accesses the boot sector on the machine's persistent 

__ storage and loads the bootloader into the system memory. 

_ It then passes execution control to the bootloader, which 

_ loads the initial operating system image from storage 

into system memory and passes execution control to the 


_ operating system. For example, in popular Linux distros, 
GRUB (Grand Unified Bootloader) acts as the bootloader 
and loads the operating system image for the machine. 
This is much like a relay race where one team member 
_ passes a baton to another to win the race. In a relay race, 
you hopefully know the members of your team and trust 
_ them to do their part for the team to get to the finish 

_ line. With machines, trust is a bit more complex. How can 
you verify that each step in the boot sequence is running 
i If our hardware or 

_ software has been compromised at any point in the boot 
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_ sequence then the attacker has the most privilege on our 
_ system and Likely can do anything they want. 


The goal of a hardware root of trust is to verify that the 


software installed in every component of the hardware 

_ is the software that was intended. This way you can 

verify and know without a doubt whether a machine's 
hardware or software has been hacked or overwritten 

| by an adversary. In a world of modchips", supply chain 
attacks, evil maid attacks’, cloud provider vulnerabilities 

_ in hardware components’, and other attack vectors it has 
become more and more necessary to ensure hardware and 
_ software integrity. 


This article is an introduction to a complicated topic; 


some sections just touch the surface, but the intention 
_ is to provide a full picture of the world of secure booting 
_ mechanisms. 


TRUSTED PLATFORM MODULE 


-ATPM (trusted platform module] is a standard for a 
_ dedicated microchip designed to secure hardware through 


PM was standardized by 


the ISO [International Organization for Standardization] 
_ and the IEC (International Electrotechnical Commission] 
_ in2009 as ISOIIEC 11889. The TPM is typically installed on 
_ the motherboard of a computer, and it communicates with 


the remainder of the system 


A TPM has the following features: 
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Integrity measurement 
Measurement is the process through which information 
about the software, hardware, and configuration of a 


system is collected and digested. At load time, the TPM 


. These hash values are 


_ reliably establish code identity to remote or local verifiers. 


The hash values can also be used in conjunction with the 
sealed storage ‘cature SSCs 


the secret. This allows the creation of data files that can 


be opened only by specific applications. 


Attestation 

Attestation reports the state of the hardware and 
software configuration. The integrity measurement 
software in charge of creating the hash key used for 
the configuration data determines the extent of the 


summary. The goal of attestation is to prove to a third 


CA). 


TPMs are manufactured with a publiciprivate key pair 


built into the hardware, known as the endorsement key. 


The endorsement key is unique to a specific TPM and is 
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_ signed by a trusted CA. The trust for attestation data is 
_ dependent on the trust for the CA that originally signed 
_ the endorsement key. 


Attestation can reliably tell a verifier which applications 


| are running ona client machine, but the verifier must still 
_ make the judgment about whether each given piece of 
/ software is trustworthy. 


| Wrapping/binding a key 
_ Amachine that uses a 


machine | 


the TPM. This process, known as wrapping or bindinga key, 


| can help protect the key from disclosure. Each TPM has 


key, which is stored within the TPM. The private portion 
of a storage root key or endorsement key that is created 
_ ina TPM is never exposed to any other device, process, 


Sealinglunsealing a key 

| A machine that uses a TPM can also create a key that has 
-not only been wrapped, but is also tied to certain platform — 
_ measurements. This type of key can be unwrapped only — 
that they had when the key was created. This process is 
known as sealing the key to the TPM. Decrypting the key 


is called unsealing. The TPM can also seal and unseal data 
_ that is generated outside the TPM. With this sealed key 
and software you can Lock data until specific hardware or 
| software conditions are met. 
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CUSTOM SILICON 

It is important to note the Limitations of TPMs and 
provide some solutions to those. TPMs can attest that 
the firmware running on a machine is the firmware the 
user wants to run, but there is no mechanism in a TPM 


for verifying that the code is secure. It is up to the user to- 


and to ensure it does 


not contain any backdoors, which is impossible if the code 


When booting a machine securely, you want the first 
instruction run on that machine to be the one you would 
expect torun. A TPMis insufficient for verifying that the 
actual bits of code to be executed are secure, so a few 
companies have created their own silicon for expanding on 
the security of TPMs. 


Google’s Titan 
For Google's infrastructure, as well as Chromebooks, 
withits own 
chip, Titan. Google open sourced? a version of Titan? (with 
both specs and code], which is under active development, 
in October 2019. In creating Titan, Google added two 
new features that did not exist in TPMs: first-instruction 
integrity and remediation. 


First-instruction integrity 


Titan observes every byte of boot firmware by interposing | 
__ itself between the boot firmware flash [BIOS] of the BMC 


(or PCH) and the main CPU via the SPI bus. Therefore, the 
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_ boot sequence for a machine with a Titan chip is different 
_ from anormal boot sequence. 


The boot sequence with Titan is as follows: 


1. Titan holds the machine in reset. 
_ 2.Titan’s application processor executes code from its 


embedded read-only memory (boot ROM). 
a e CSTR, 


| 4. Titan verifies its own firmware using public-key 


apaga an AREAN CEN GPENINVE TET Zhe 


5. Titan loads the verified firmware. 


_ 6 Titan verifies the host's boot firmware flash (BIOS/UEFI). 


7. Titan signals readiness to release the rest of the 


machine from reset. 


| 8. The CPU loads the basic firmware (BIOS/UEFI] from the 


boot firmware flash, which performs further hardwarel 
software configuration. 


9. The rest of the standard boot sequence continues. 


Holding the machine in reset while Titan 


cryptographically verifies the boot firmware, Titan enables 
__ the verification of the first instruction. Titan knows what 
boot firmware and operating system booted on your 

_ machine from the very first instruction. In fact, you even 
-know which microcode patches may have been fetched 
before the boot firmware’s first instruction. 


Remediation 


| What happens when we need to patch bugs in Titan’s 
_ firmware? This is where remediation comes into play. In the 
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~ event of patching bugs in the Titan firmware, trust can be 
__ reestablished through remediation. Remediation is based 
~ onastrong cryptographic identity. To provide a strong 


_ identity, the Titan chip manufacturing process generates — 
_ unique keying material for each chip. The Titan-based 


identity system verifies not only the provenance of the 
chips creating the CSRs (certificate signing requests], but 
also the firmware running on the chips, as the code identity 
of the firmware is hashed into the on-chip key hierarchy. 
This property allows Google to fix bugs in Titan firmware 


and issue certificates that can be wielded only by patched | 


The Titan-based identity system enables back-end 
systems to securely provision secrets and keys to 
individual Titan-enabled machines or jobs running on those 


_ machines. Titan is also able to chain and sign critical audit 
_ logs, making those logs tamper-evident. This ensures that 


audit logs cannot be altered or deleted without detection, 
even by insiders with root access to the relevant machine. 


_ Microsoft open sourced" the specs for its chip, Cerberus" 
(at the time of writing this article, only the specs have 

_ been open sourced]. Like Titan, Cerberus interposes on 

_ the SPI bus where firmware is stored for the CPU. This 

allows Cerberus to continuously measure and attest these 
accesses to ensure firmware integrity and thereby protect 
against unauthorized access and malicious updates. 


_ Apple is a poster child for secure booting devices. Most 
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~ people remember when the FBI wanted a backdoor into 
iPhones and Tim Cook refused.° Between Macs, iPhones, 
and Chromebooks, an industry standard for products 
includes security by default. 


For Apple machines, secure boot is done with Apple's 


| T2 chip.' Ivan Krstic of Apple gave a talk at Black Hat 2019" 
detailing the boot process for a Mac with Apple's T2 chip. 


Apple's requirements for T2 were: 


| = System software authorization (server-side downgrade 


protection). 


(not portable). 


» Secure boot policy protected against physical tampering. 
= System can always be restored to a known-good state. 


The boot sequence for a machine using a T2 chip is as 


follows: 

| = The machine is powered on. 

= T2 ROM is loaded and executed. 

_ » T2 ROM passes off to iBoot, the bootloader. 

= The bootloader executes the bridgeOS kernel, the kernel 


for the T2 chip. 


= The bridgeOS kernel passes off to the UEFI firmware for 


the T2 chip. 


| = The T2 chip then allows the CPU out of reset and loads 


the UEFI firmware for the CPU. 


| =» The UEFI firmware for the CPU then loads macOS 


booter. 
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i” The macOS booter then executes the macOS kernel. 


One important design element of the T2 chip is how 


Apple verifies the version of MacOS running on a computer. 
_ T2 verifies the hash of MacOS against a list of approved 
hashes for running. Apple is in a unique position to have this 
level of verification since they own the entire stack and 
prevent users from running any other OS on their devices. 
If you would like to go deeper into the internals of the T2 

_ chip, read the slides for Ivan Krstic’s Black Hat talk.” 


_ PLATFORM FIRMWARE RESILIENCY 

Chip vendors are investing in PFR (platform firmware 

__ resiliency] based on NIST (National Institute of Standards 
and Technology] guidelines." These guidelines focus on 

_ ensuring the firmware remains in a state of integrity, 
detecting when it has been corrupted, and recovering the 
_ pieces of firmware back to a state of integrity. 


PFR addresses the vulnerability of enterprise servers 


that contain multiple processing components, each 

_ having its own firmware. This firmware can be attacked 
by hackers who may surreptitiously install malicious code 
-ina component's flash memory that hides from standard 
system-level detection methods and leaves the system 
permanently compromised. 


The PFR specification is based on the following principles: 


__= Protection, ensuring that firmware code and critical 
_ from corruption, such as the process for ensuring the 


_ authenticity and integrity of firmware updates. 
| Detection, SAEN 
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-= Recovery, restoring firmware code and critical data toa 
-state of integrity in the event that any such firmware code 


_ or critical data are detected to have been corrupted, or 

_ when forced to recover through an authorized mechanism. 
Vendors have been building features around the NIST 

_ guidelines for PFR. Intel® and Lattice Semiconductors" 

= each has sucha product. 


_ UEFI SECURE BOOT 

/ UEFI Secure Boot” is designed to ensure that EFI binaries 

_ trusted certificate. When a machine using UEFI Secure 

/ Boot powers on, the UEFI firmware validates that each EFI 
binary either has a valid signature or the binary’s checksum 
is present on an allowed list. Counter to the allow list 

/ is a deny list that is also checked to ensure no binary’s 
checksum or signature exists on it. 

_ list of trusted certificates and checksums as EFI variables. 
| These variables get stored in non-volatile memory used 

by the UEFI firmware environment to store settings and 

| configuration data. 


The UEFI kernel is extremely complex and has 


millions of lines of code. It consists of boot services and 
_ runtime services. The specification’ is quite verbose and 


complex. The UEFI kernel is a common vector for many 


| vulnerabilities since it nes Sala 
_ code used on many different platforms. | kernel 


_ is shared on multiple platforms, making it a great target 


for attackers. Additionally, since only UEFI can rewrite 
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__ itself, exploits can be made persistent. This is because UEFI 
_ SPI flash. Even if a user were to wipe the entire operating 
"system or install a new hard drive, an attack would persist 

_ inthe SPI flash. 


| INTELS BOOT GUARD 
Boot Guard is Intel's solution to 


uard works b 
ic key of the sign 


~ programmable fuses [FPFs], a one-time programmable 
_ memory inside Intel Management Engine (ME), during the 
_ manufacturing process. The machine then has the public 


key of the BIOS and it can verify the correct signature 


during every subsequent boot. However mmama 


The problem with Boot Guard is that only Intel or the 


_ This makes it impossible to use coreboot, LinuxBoot, or any 
other equivalents as firmware on those processors. If you 
tried, the firmware would not be signed with the correct 
key, and the failed attempt to boot would brick the board. 


Matthew Garrett wrote a great post about Boot Guard 


that highlights the importance of user freedom when it 
comes to firmware’. The owner of the hardware has a right 
-to own the firmware as well. Boot Guard prevents this. In 
the security keynote at the 2018 Open Source Firmware 

< Conference®, Trammel Hudson described how he found a 
vulnerability to bypass Boot Guard, CVE-2018-12169%. The 

| bug° allows an attacker to use unsigned firmware and 

_ boot normally, completely negating the purpose of Boot 
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_ Guard. Because Boot Guard is tied to the CPU, it does not 
have the control that a custom silicon hardware root of 

_ trust has when it comes to other firmware for components 
in the system. 


__ SYSTEM TRANSPARENCY 

_ The Mullvad virtual private network service published a 
paper on what it calls system transparency,” which is aimed 

| at facilitating trust for the components of a system by giving 
every server a unique identity, limiting the attack surface 
and mutable state in the firmware and allowing both owners 
_andusers to verify all software running ona platform 
starting from the first instruction executed after power on. 


ST accomplishes these goals by following seven 


principles: 

_ 1. Identity binding. A key ceremony of each server to 

_ bind the server's unique identity with a difficult to forge 

__ physical artifact like a video. 

_ 2. Physical write-protection of the firmware. Writable 
code sections are a mutable state, so System Transparency 
| limits the possible changes to this critical piece of code. 
Read-only code also serves as a root of trust for all other 
_ software-enforced security mechanisms. 

| 3. Tamper detection. Attackers cannot be stopped from 

_ changing the content of the firmware flash by replacing 

_ the actual chip. So, violations of the physical integrity of 
the server hardware need to be detectable. 

_ 4. Measured boot. System Transparency has the goal to 

| give all parties insight into what code was run as part of 


__ the system boot. A measured boot in combination with 
_ remote attestation allows third parties to acquire a 
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_ cryptographic log of the boot. 

__ 5, Reproducible builds. Ensures that if a binary artifact is 

_ built once, it can be built again and again and produce the 
same artifact. This establishes a verifiable link between 

_ the human-readable code and the binary that was attested 
using the measured boot mechanism. 

_ 6. Immutable infrastructure. System transparency only 

_ works when changes to the operating system are limited. 
Allowing somebody to log into the system and make 
arbitrary changes invalidates all guarantees of a measured 


boot. 


| 7. Binary transparency log. All firmware and OS images 
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of the system can monitor this | 
log for new entries and catch 
malicious system owners booting 
backdoored firmware on new 
servers. 


THE IMPORTANCE OF OPEN 
SOURCE FIRMWARE 

Securing the boot process 

with a hardware root of trust 

has various implementations 
throughout the industry. Without 
open source firmware, the 
proprietary bits of the boot 
process still lack the visibility 

and auditability to ensure 
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_ that software is secure. Even if you can verify through 

a hardware root of trust that the hash of proprietar 

__ firmware is the hash known to be true, LETTE, 
contain any backdoors. Through this visibility you can also 

| without 


_ gain ease of use in debugging and fixing problems 


_ machines and their components; it is in the CPU (central 
processing unit), NIC (network interface controller], SSD 

_ (solid-state drive], HDD (hard-disk drive), GPU (graphics 

_ processing unit), fans, and more. To ensure the integrity of 
-a machine, all these components must be verified. In the 

_ future, these custom silicon chips will interpose not only on 
the SPI flash but also on every other device communicating 
-with the BMC. 


If you would like to help with the open source firmware 


movement, push back on your vendors and the platforms 
_ you are using to make their firmware open source. 
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